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ABSTRACT 

Long duration human space missions, as planned in the 
Vision for Space Exploration, will not be possible without 
applying unprecedented levels of automation to support 
the human endeavors. The automated and robotic 
systems must carry the load of routine “housekeeping” 
for the new generation of explorers, as well as assist 
their exploration science and engineering work with new 
precision. Fortunately, the state of automated and 
robotic systems is sophisticated and sturdy enough to do 
this work - but the systems themselves have never been 
human-rated as all other NASA physical systems used in 
human space flight have. 

Our intent in this paper is to provide perspective on 
requirements and architecture for the interfaces and 
interactions between human beings and the astonishing 
array of automated systems; and the approach we 
believe necessary to create human-rated systems and 
implement them in the space program. We will explain 
our proposed standard structure for automation and 
robotic systems, and the process by which we will 
develop and implement that standard as an addition to 
NASA’s Human Rating requirements. 

Our work here is based on real experience with both 
human system and robotic system designs; for surface 
operations as well as for in-flight monitoring and control; 
and on the necessities we have discovered for human- 
systems integration in NASA’s Constellation program. 
We hope this will be an invitation to dialog and to 
consideration of a new issue facing new generations of 
explorers and their outfitters. 


An exploration program featuring long duration human 
space flight missions, such as the Vision for Space 
Exploration (VSE) proposed by President Bush several 
years ago, requires several very new approaches to 
operations - approaches that do not fit the paradigms of 
current or past human space missions. 

In historic as well as current human space programs, the 
common approach to mission operations during flight 
has been to assign system and subsystem management 
responsibilities to individuals and groups of flight 
crewmembers and ground-based mission controllers. 
This approach is not workable for the VSE, because it 
cannot be scaled to include a variety of flight and 
planetary surface assets simultaneously. The mission 
operations practitioners are discovering that this 
approach is extremely difficult to maintain even with 
current programs: the approach is very labor-intensive, 
which makes it both increasingly expensive, and 
increasingly dependent upon a shrinking pool of 
technically educated workers. 

Fortunately, the space vehicles, surface vehicles, and 
shelters of the Constellation Program and other 
exploration programs will include unprecedented and 
pervasive automated systems, which will be able to 
manage routine “housekeeping” engineering activities 
and environmental life support necessities. Automated 
support will allow the humans - both flight crewmembers 
and ground-based operators - to spend their time and 
energy dealing with the unanticipated, unexpected and 
unpredictable aspects of the missions. Robotic systems 
- automated systems that can do physical work similar 
to the work people can do - will be continuously active 
and self-guiding. For this reason, they will be able to 
perform the “grunt work” that is either too routine or too 
dangerous for people to spend time doing. The control 
of robotic systems will span a broad spectrum of 
methods, from teleoperation to autonomy, just as the 
purposes of the systems will span a broad spectrum of 
work from routine environmental management to mobility 
and construction. 

Systems engineering will be conducted holistically, with 
people in space and in operations control centers on 
Earth considered as elements of the overall system. 
Programs will apply their collective systems engineering 
capabilities to developing more than just hardware and 
software; they will develop the processes used to make 
and maintain hardware and software for extended use; 
the methods used to operate the integrated systems; 
and the ways in which both explorers and Earth-bound 
operators are prepared and trained to use the systems. 

Some automated systems will be required to maintain 
the ship or habitat environment as a substitute for the 
benign environment of Earth. Such systems (ENose for 
example) are already being tested on the International 
Space Station (ISS) with significant success. Other 
automated and robotic systems will substitute for 



workforce elements that perform routine tasks, such as 
clerks and physical laborers. Such systems will include 
a spectrum of devices, from automated inventory 
management systems to monitor supplies, to automated 
construction equipment that will move habitat modules or 
build regolith barriers. 

Automated robotic systems may even be used to explore 
dangerous lunar surface areas or make useful materials 
from in situ resources. Such systems will be much more 
than extensions of a mission control console operator’s 
hands. These automated systems will help to keep the 
explorers safe, help them to do their work better, and 
help them to implement solutions to the expected stream 
of unexpected problems presented by their unknown 
surroundings. 


It goes on to explain the human-rating process, 

presenting three basic tenets: 

1. Human-rati ng is the process of designing, 
evaluating, and assuring that the total system can 
safely conduct the reguired human missions. 

2. Human-rating includes the incorporation of design 
features and capabilities that accommodate human 
interaction with the system to enhance overall safety 
and mission success. 

3. Human-rating includes the incorporation of design 
features and capabilities to enable safe recovery of 
the crew from hazardous situations. 


HUMAN RATING 

It is important to understand the nature of a human-rated 
system, and we can start to explain this by asking a 
specific question: What is different about certifying the 
systems that carry human beings into space, from the 
systems that carry unique robotic payloads into space? 

NASA’s recently updated Procedural Requirement for 
human-rated systems (NPR 8705. 2B) includes several 
new answers to this question, and these answers have 
been derived through study of the human experience in 
space exploration from the time of Mercury and Apollo 
programs, to the current Space Shuttle and International 
Space Station programs. 



The NPR concludes its definition by stating: “Human- 
rating is an integral part of all program activities 
throughout the life cycle of the system, including design 
and development; test and verification; program 
management and control; flight readiness certification; 
mission operations; sustaining engineering; 
maintenance/upgrades; and disposal. ” 

The NPR describes the methods by which systems are 
certified as human-rated. What is important here is that 
our human space flight programs have not really 
considered the necessity for developing human-rated 
automation and robotics, because these systems are 
available for the first time to flight systems under 
development now - flight systems such as those that 
make up the Constellation Program, or the newest 
elements of the ISS. The level of automation now 
available for both flight and ground operations is 
unprecedented, but the interfaces and interactions 
between people and those systems has been examined 
in only a preliminary manner. Both human factors 
engineers and robotics engineers agree that there are 
physical and attitudinal issues to consider when they put 
people together with automation for any operational task 
- but especially for complex tasks, performed in hostile 
environments, that could last for months or years. 

Human factors engineers confront the physical issues in 
every system they must work with: 

■ making the system operable 

■ making it useful 

■ designing it to help prevent and mitigate errors 


A variety of human-rated launch vehicles, from the Apollo Program’s 
Saturn V, to the Space Shuttle and the Constellation Program’s Ares I. 
Originally conceived as a cargo launch vehicle only, NASA authorized 
a study regarding human-rating for the Ares V in November 2008. 
(These NASA graphics are in the public domain.) 


They are able to address these issues in a relatively 
straightforward manner if the elements of a system are 
always operated “hands-on” by a person, although the 
issues are not always easily solved. 


The new NPR 8705. 2B states: “A human-rated system 
accommodates human needs, effectively utilizes human 
capabilities, controls hazards with sufficient certainty to 
be considered safe for human operations, and provides, 
to the maximum extent practical, the capability to safely 
recover the crew from hazardous situations.” 


One difficulty is both cognitive and psychomotor: people 
frequently expect any systems they use to provide 
performance options the systems were not designed for, 
and frequently attempt to “force” physical system 
controls until the controls fail. (Did you ever “freeze” 
your computer trying to make it perform too many 


operations?) Another difficulty is anthropometric: people 
who use the systems come in a variety of shapes, sizes, 
strengths and perceptual sensitivities, and they all must 
be able to operate the systems. (How well does the 
keyboard on your laptop fit your typing capability and 
comfort? How about the keyboard on your Blackberry?) 

Human factors engineering must include considerations 
like shapes and structures of switches and controls, the 
ways in which information is presented to crewmembers 
on a computer screen, and ways in which systems warn 
crewmembers about malfunctions. All these physical 
issues of human engineering become more complex in 
space, where the humans must operate the systems 
under circumstances such as great acceleration or 
micro-gravity. (Imagine sending your friend a coherent 
text message while accelerating at three gravities, and 
with all that rocket noise...) 

So the physical issues related to human-systems 
integration are difficult, but relatively straightforward. The 
affective or attitudinal issues that automated systems 
create for people are much more subtle and difficult to 
deal with using just physical design solutions, because 
these issues involve human emotional responses to 
automated systems themselves. The human factors 
engineers and the systems design engineers must work 
hand in hand to develop automation and robotics that 
crew members will trust - systems that crew members 
will consider reliable enough to entrust with their lives 
and health while in a distant and hostile environment. 
Crewmembers must believe that they can always predict 
the system’s behavior in a given situation - and that the 
system’s behavior will never be hazardous to them. 

Consider how long it might take you to build such trust 
for another person, and then imagine the difficulty in 
trusting a machine in the same way. A mechanical 
device clearly does not share your culture, your value 
system, and your emotional foundations. It emulates 
human performance by making decisions regarding its 
behavior based on a relatively limited set of possible 
responses to a variety of programmed situations, and 
then communicates those decisions to you... 

If that system were making decisions that affected your 
survival, you would want to have final authority to shut 
the system down if, in the last instance, you disagree 
with its operational direction. Of course this option is 
actually required for all human-rated systems: the 
humans must be able to override system operation, to 
manually control a normally automated function - so 
long as that override does not cause a catastrophic 
event. Does this mean that the automated system must 
determine whether the transition to manual control will 
be more hazardous than its automated direction? Does 
this requirement invite strange “arguments” between the 
crew and the navigation computer, regarding who is the 
better pilot? 


considering how to human-rate an automated system 
that may ultimately be responsible for human lives. 


A NEW DESIGN STANDARD 

NASA uses design standards as drivers for developing 
program or system requirements. Standards are always 
the best knowledge available regarding the topic under 
consideration. A standard is a rule or principle that is 
used as the basis for judgment, something considered 
by authorities or by general consent as a basis for 
comparison. Standards exist within NASA for hardware 
design, for electrical system design, for the official colors 
and shape of the NASA logo, and so on - and even for 
human factors engineering, in the well-known STD-3000, 
NASA’s Man-System Integration Standards (MSIS). The 
authors were among the team that used STD-3000 to 
derive the Human-Systems Integration Requirements 
(HSIR) for the Constellation Program. 

HUMAN-SYSTEMS DESIGN NEEDS - Standards are 
living rather than static, because when new research is 
completed and new principles or measurements are 
discovered, standards must be updated to continue as 
authoritative. An update and upgrade of NASA’s STD- 
3000 is essential, and is being developed presently, 
under the leadership of the Habitability and Human 
Factors Branch at Johnson Space Center. The upgrade 
will likely add new volumes and revise existing volumes, 
because research has added a great deal to the human 
factors knowledge within the agency over the last twenty 
years. The update will address the existing in-space 
(milli- and microgravity) design requirements, which 
need to be brought up to date, based on both flight 
experience and on a series of carefully-planned and 
carefully-conducted experiments onboard the ISS. The 
new STD-3001 will again be based on experiment and 
should address planetary environments: such as Mars, 
the moon, and event asteroids, as well as shipboard 
environments. 

Logically, all these sections do not need to be developed 
at once; the microgravity and lunar environments should 
be addressed immediately, and the “deep-space” design 
requirements should be developed as we gain additional 
experience and experimental knowledge. In support of 
the revision and creation of these volumes, a major effort 
should be undertaken to develop a research program on 
both ISS and on earth to systematically examine human 
performance in long-duration off-earth environments. 
The experimental facilities for the lunar environments 
should include both earth-based assets (neutral 
buoyancy facilities, suspension facilities, and the like); 
and the ISS, outfitted as a testbed for research on 
strength, endurance, and performance, as well as design 
concepts for long duration flight. 


You can see the difficult philosophical and policy issues 
related to control and control authority when we begin 




Robotic systems like the Mars Exploration Rovers are operated by 
programming instructional sequences and sending them to Mars by 
radio - there is a time latency of up to twenty minutes, so the systems 
can hardly be teleoperated in real time! It will be many years before 
humans are working side-by-side with robots on the Martian surface. 
(NASA photo in the pubic domain.) 

A STANDARD FOR HUMAN-RATED AUTOMATION 
AND ROBOTICS - A new document is now needed, 
analogous to MSIS or written as an additional section for 
it. This new documentation should address the human- 
rating issues related to: 

■ Automated systems that will monitor and control 
any elements of human space flight vehicles and 
habitats (such as life support systems, flight control 
systems, engineering “housekeeping” functions, 
and others) 

■ Robots which are teleoperated, or controlled directly 
by human beings through direct manipulation or 
other means involving telepresence (such as the 
ISS robotic arm, or the Mars Exploration Rovers) 

■ Robots which are intended to be collaborative 
automated workers (often in the presence of human 
workers), and which may be subject to similar 
functional constraints as humans at work (such as 
reach, visibility and situational awareness, etc.) 

We call the new document the Automation and Robotic 
Systems standard, or ARS. The ARS will have to be 
created by discipline experts in a variety of disciplines, 
with the same breadth of perspective on these issues 
as human engineers will need in developing the rest of 
STD-3001 . Human factors engineers will be critical to 
the ARSS, but so will robotics engineers, behavioral 
scientists, space systems engineers, computer 
scientists, mission operations systems engineers, and 
others. The authors have actually proposed that the 
new ARS standard be developed under the banner of 
the NASA Engineering and Safety Center (NESC) 
because that organization’s perspective and influence 
crosses center and discipline boundaries with multi- 
disciplinary credibility. 


CHARACTERISTICS OF A NEW STANDARD - We 
believe there are other important characteristics the 
new standard should demonstrate: 

1. It should include both process and technical points. 
The ARS should not only set measures for the 
automation and robotic products themselves; it 
should guide the methods by which these products 
are designed and developed, and especially the 
ways in which automated and robotic systems are 
used by people in the context of exploration. 

2. It should not re-invent current standards. Where 
applicable and feasible, the ARS should reference 
current standards for the human interface with 
automated and robotic systems (an example might 
be the Federal Aviation Administration’s standard 
for design of human operated automated systems, 
or the United State Navy’s standards for monitor 
and control of environmental systems in ships). 

3. ARS should identify and address NASA’s unique 
applications of automated and robotic systems - 
those applications related to human space flight and 
exploration. For example: while some of ARS may 
be derived from similar standards for systems like 
Unmanned Aerial Vehicles, there are important 
differences even in teleoperated systems which are 
thousands or millions of miles away and introduce 
major signal latency issues. 

4. ARS should help programs by including guidelines 
for developing requirements and verifications. We 
believe that actual examples or templates would be 
most useful in this respect. 

5. It should define and describe the full spectrum of 
automation and robotics. ARS must address not 
only teleoperated physical robots, but autonomous 
robots that operate in isolation or near humans, and 
automated monitor and control systems that 
operate shipboard or habitat-based physical 
systems. Each of these will have specific 
requirements for human interface and interaction. 

6. ARS should contain its own guidelines for change 
and future modification. Standards drive system 
requirements for programs and project; but human 
knowledge becomes more complete and accurate 
over time, so standards must be themselves driven 
to updates by new knowledge. 

KEY ISSUES IN HUMAN-ROBOT INTERACTION - We 
believe there are certain key issues the standard must 
deal with in the area of human interaction, and these 
issues are broader than the traditional physical human 
interface issues that are so well understood by human 
factors engineers. The first of these issues is the 
assignment and transfer of control authority among 
systems, and between human beings and automated 
systems. Policies will have to be developed that govern 
how control authority is initially assigned among people 


as well as among the automated systems; and policies 
will also have to exist that define the reasons and 
protocols for transferring control from person to person, 
from person to system, and from system to system. 
The policies will have to address these issues for both 
nominal and off-nominal task execution and operations. 

The importance of this issue becomes very clear when 
you consider the contrast between current mission 
operations paradigms for human space missions, and 
required operations approaches for long-duration space 
flights with very long latency in signal. How can ground- 
based operators take control of rapidly evolving 
situations on a space ship that is millions of miles away, 
with a round-trip time for signal and message transfer of 
thirty minutes? And how can a single operator keep 
control authority, when there may be multiple robotic 
assets operating simultaneously on the lunar surface? 

The mechanisms that will actually make the transfers 
will have to be included in the standard too. These 
mechanisms must prevent inadvertent commanding of 
assets, but at the same time allow human intervention 
or autonomous action, when necessary, to preserve 
crew or operator safety. Our compelling example: an 
explorer walking across the lunar surface in a pressure 
suit, accompanied by her robotic assistant, which is a 
huge six-legged spider with powerful manipulators (the 
planned ATHLETE robotic system). Our explorer does 
not want the robot to walk too far ahead of her, or too 
far behind her, but she certainly does not want 
ATHLETE to touch her fragile suit - unless she falls and 
breaks her leg! Then, she wants her giant robotic 
assistant to pick her up and carry her back to the base 
safely - even if she is unconscious and cannot ask for 
this help... 



NASA’s test version robotic mobility system ATHLETE (All-Terrain 
Hex-Legged Extra-Terrestrial Explorer) carrying a lunar habitat module 
during tests of future moon systems at Moses Lake, Washington. 
Photo from NASA Jet Propulsion Laboratory public web site. 

Another important issue is the manner and frequency 
with which each system will report to the humans in 
command. For example: if an automated environmental 
management system is programmed to make minor 
adjustments in atmospheric conditions based on trends 
it measures during regular monitoring, how often must it 


report those adjustments to the people? If a single 
adjustment corrects the trend, perhaps the system must 
report only once, in a briefing to the commander before 
the end of the day. If the adjustment does not correct 
the trend, perhaps the system must report quickly, so 
that a human (or robotic) repair team is notified in time 
to prevent problems. 

STRUCTURE OF THE ARS INTERFACE SECTIONS - 
We believe that there should be several sections in the 
initial release of the ARS document that specifically 
address both physical and functional interfaces and 
interactions among human beings and automated or 
robotic systems. The standard will be iterated over time 
into a structure that is most useful, and most easily used. 

The first section should address design considerations 
and design requirements for assembly and integration of 
automated systems and of worker robots. This section 
would describe a standardized set of robotic functions 
and capabilities, preferably modular in nature so that 
robots for a particular mission could be assembled from 
a standard functional design portfolio to meet the 
mission goals. The various physical subsystems for 
robots would be available for a mission designer 
basically “off-the-shelf,” based on modular functional 
design necessities and collective operational 
requirements. 

Chapters of this first section of the standard would 
address propulsion or locomotion, command and control, 
communications, mechanisms, end effectors, and 
sensors. One chapter must address the integration of 
the various systems, and one chapter must address the 
levels of autonomy a particular design can achieve. In 
addition, there must be at least one chapter on 
requirements for maintenance of the robots by humans 
(and ultimately by other robots), but this chapter will only 
address those requirements that are unique to robot 
maintenance and are not found in other maintenance 
sections of the updated NASA STD-3001 . 

This approach to function-based standardization will 
reap huge benefits in long-duration missions in terms of 
logistics and spares, maintenance, and ground and flight 
crew training. While it can encourage the use of a wide 
variety of individual robots, the assembly of those robots 
from standardized components will certainly make them 
more affordable and more reliable. The flow-down 
benefits to short-term missions and the design of free- 
existing robots are apparent but are not drivers. 

The second interface section of ARS should address 
design considerations and design requirements for 
development of systems that will be manipulated - 
maintained, transported, or stowed - by robots. This will 
include design requirements for developers of spacecraft 
that will be serviced by robots; by “spacecraft” we refer 
to robotic or uncrewed planetary satellites and 
propulsion modules, as well as in-space and planetary 
crewed vehicles, including habitats. 


Since we are including essentially all future spacecraft, 
this section will have very deep and long term 
ramifications. It will address the work envelopes that the 
standard robots must perform within, including issues 
such as: the strength capabilities of these robots; the 
hardware and “humanware” interfaces they are capable 
of manipulating (fluid, electrical, and data connectors; 
fasteners; volumes and dimensions, etc.); and the 
structural and dynamic characteristics of the hardware. 
These are in almost every way analogous to the design 
issues addressed in other areas of the updated NASA- 
STD-3001, but specifically applied to automated and 
robotic systems. This is necessary for a variety of 
reasons, not least because humans and robots face the 
same sorts of physical constraints when performing 
tasks: both must be able to detect (“see,” in the case of 
humans) and reach a hardware interface to manipulate 
it, and the manipulated component must conform to the 
constraints of the human (e.g., hand size, strength) or 
the robot (e.g., tool fitting size, cybernetics). 

Notice the reference to “humanware” as manipulated by 
robots. We expect that, in addition to performing other 
tasks, some robots will transport or be transported by 
human beings; some will provide temporary life support 
for people; some will perform surgery or other health 
care procedures on humans; some will act as task 
assistants; and most will understand and react to human 
commands (either verbal, visual, or digital) and provide 
information to humans in understandable formats. 
(These issues will need to be addressed in human 
interface standards with other, non-robotic automated 
systems, as well.) 

A new approach to design will be needed in a third 
interface section: a standard for space hardware 
systems that are serviceable by both humans and 
robots. The design requirements derived from this part 
of the standard will apply to Replaceable Units (RUs), 
including Orbital Replaceable Units (ORUs), Inspace 
Replaceable Units (IRUs), and Planetary Replaceable 
Units (PRUs). 

We expect that most in-space and planetary structures 
will have RUs. This design standard will have to include 
the packaging of all RUs such that they may be removed 
and replaced by either a human or a robot. The 
overarching concept is that RUs should be “plug-and- 
play,” to the fullest extent possible, and that either 
humans or robots should be able to “plug” them. This 
approach was begun in ISS robotics, for the Remote 
Manipulator System and Special Multipurpose Dexterous 
Manipulator System. This new standard should expand 
the issue to all RUs, to allow operational flexibility. In 
most future cases, when robotic systems achieve a level 
of refinement they do not now have, these requirements 
will be limited by human capabilities. This constraint will 
still allow for redundancy of servicing methodologies. 

One chapter of this section will address RUs to be 
manipulated in an unpressurized or low-pressure 
environment (“low-pressure” means that pressure level 


below which astronauts require pressure suits). The 
requirements for envelopes, strength, and other 
manipulative factors must be covered in the revised 
STD-3001. Those RU requirements should be 
referenced to emphasize the special constraints of 
suited task performance. The chapter should address 
those characteristics of the RU that make it “plug-and- 
play” in the unpressurized environment - including 
connectors for fluid, data, and electrical; 
handling/transportation interfaces; alignment and sliding 
guides; tool interfaces; and fastening. Both robot/human 
RU interfaces and RU/system interfaces must be 
addressed in the chapter. 

A chapter will address “shirtsleeve” or pressurized 
environments. Most issues will be the same as for 
unpressurized environments; but in many cases, the 
interfaces for both humans and robots can have a finer 
“grain” - smaller fasteners may be used, less robust 
connectors, and finer sensory cues than are possible in 
low-pressure environments. This design philosophy and 
approach will be driven by the strong increase in human 
capabilities in this environment. The modularity of the 
RU design philosophy will derive from the need for 
robotic support, again, to allow operational flexibility. 

We believe that the shirtsleeve maintenance 
environment will remain the domain of humans for some 
time to come, but the need for robotic assistants to 
perform at micro or even smaller levels will drive these 
requirements. These robotic workers will be an essential 
part of the flight crew for any long-duration mission 
outside Low Earth orbit, because they will not consume 
resources that must be transported from the earth’s 
surface (oxygen, water, foodstuffs). They will be 
necessary to keep the crew size down and to free the 
human explorers from routine housekeeping duties, 
allowing the people to perform flight and scientific 
mission tasks that are non-routine and involved with the 
surprises and uncertainties of exploration missions. 
(While human mental and physical flexibility will surpass 
that of the robots, the application of this standard to the 
shirtsleeve environment will support overall mission 
goals by removing humans from routine operations 
where automated systems excel.) 



AS I MO, Honda’s autonomous robotic system, prepares to conduct the 
Detroit Symphony Orchestra. Orchestra members reported that the 
robot was easy to follow and very precise in its movements. Honda 



Research Institute, Advanced Telecommunications Research Institute 
and Shimadzu Corporation have collaboratively developed the world’s 
first Brain Machine Interface technology to enable teleoperation of a 
robot by human thought alone. (Photo is in the pubic domain.) 

TRUSTING THE SYSTEMS - There are many reasons 
for human-rating the automated and robotic systems that 
will assist us in space exploration, but perhaps the most 
compelling is that the explorers must feel that they can 
trust the systems they use as exploration tools. Our 
American cultural view of robots and automation 
precludes an automatic, dependent trust on such 
systems: consider the modern folklore related to 
automation and robotics, expressed in movies such as 
Terminator and Space Odyssey! (The Japanese cultural 
view, by contrast, is that robots are much more benign, 
as demonstrated by depiction of robots as toys and 
protectors of human interests in television programs like 
Transformers; and in their development of robotic assets 
like Honda’s Asimo, which recently conducted the Detroit 
Symphony Orchestra...) 

For that reason, the human-rating standard for these 
automated systems must address fault detection in a 
very complete way. Design of fault identification, 
reporting and recovery methods must be carefully 
addressed in the standard; and verification methods for 
each must be explained and modeled there. Especially 
important will be the fault reporting interface between the 
systems and people - how faults are reported, how 
frequently, and with how much detail. Increased depth 
of fault reporting can bring increased crewmember trust, 
but if a system’s reporting protocol can’t “get to the good 
stuff” quickly enough, there is risk of perceptual slips by 
those receiving the reports. 

In addition, the nature and operating standard for self- 
diagnostics in automated systems must also be well 
explained in the standard, and verification methods for 
ongoing self-diagnostics must be explained thoroughly. 
After all, self-diagnostics are the “conscience” of an 
anthropomorphized automated system... 

ANTHROPOMORPHIZING THE SYSTEMS - There is 
danger in considering an automated system to be a 
“partner” or “helper” rather than a tool, and inspiring too 
much of the wrong type of trust in the system. The 
danger is that of unrealistic expectations from the 
system. Other human beings will always share certain 
worldview elements with us, based on our shared 
experiences and shared value sets. Our automated 
systems cannot share our experiences because they do 
not have our complex sensorium, nor our holographic 
processing capability that allows analog comparisons 
and pattern recognition even among unlike items and 
events. 

Nevertheless: we anthropomorphize the systems if we 
can because we are people and we use ourselves as the 
analog for nearly all activity we see in the world! Take a 
look at ASIMO in the previous column and try to think of 
it as “it” instead of “he.” That recognition is even more 
difficult with android-type robots like Japan’s Repliee, 


which has appeared on Japanese television talk shows 
wearing a cute skirt and a “Hello Kitty” sweatshirt... 

ARS LABORATORY AND TESTBED - The authors 
have considered that the ARS standard will surely lead 
to new approaches in development and implementation 
of automated and robotic systems - not just new design 
approaches, but new approaches in the ways human 
beings must interface and interact with those systems. 
This will include new attitudes toward using the systems, 
as well as new psychomotor skills. One crewmember 
directly told one of the authors, “We want HAL 9000, to 
take care of our needs and our environment, but we 
don’t want HAL’s personality...” 

As a “next step” to help implement the standard in a 
standardized way, and to work out the interactive 
protocols among people and systems, we propose 
establishing a distributed Automation & Robotic Systems 
Laboratory and Testbed. This facility would be used to 
develop automated system elements, test operations, 
and train both crewmembers and mission operations 
personnel in their use. This distributed facility would be 
created and maintained at several NASA centers 
simultaneously - probably Ames Research Center and 
Jet Propulsion Laboratory in California, and Johnson 
Space Center in Texas. Each center would specialize in 
development, test, and training related to specific robotic 
or automation elements within the integrated system of 
human exploration operations. 

We will have to complete the ARS standard itself in 
order to derive the types of program needs that should 
be addressed by the ARS lab and testbed, and therefore 
the design of the facility, but we can make certain 
conjectures based on what we have forecasted here 
regarding operations issues. For example, we know 
there should be development and test capability for 
integrated multi-asset operation (of various combinations 
of teleoperated and autonomous assets). This capability 
might be spread among all three centers, with mission 
control workstation facilities at JSC and JPL (where 
human and robotic missions are already operated), and 
asset simulation capability at ARC (the leading center for 
intelligent systems development). Development and test 
might take place at the centers most experienced in a 
specific type of operations, and training of operations 
personnel and crewmembers would take place at the 
center typically responsible for that type of training. 

We look forward to developing a comprehensive plan for 
the ARS lab and testbed following completion of the 
ARS standard. 


CONCLUSIONS 

Unprecedented automated and robotic systems will 
make long duration space missions both possible and 
productive, but they will also force everyone who plans 
our human space flight programs to pay attention to how 
explorers will control and interact with these systems. 



Our NASA approach to human-rating the systems that 
take people into space must be applied to the automated 
and robotic systems that will help people stay there for 
long terms. The new NPR for Human Rating makes this 
application more likely and more easily accomplished. 
We must develop a standard for these systems that can 
drive programmatic requirements, and provide guidance 
to a development and test facility for the systems 
themselves. That challenge is bigger than any individual 
NASA center, and will demand the collaborative work of 
several centers to achieve. 

Please consider this paper a call for conversation and 
collaboration, as we begin the task of making automated 
and robotic systems more useful, and the task of helping 
people to use the systems better! 


Lynn Baroff is the Principal Investigator for the proposed 
standard development project referred to in this paper, 
the Automated and Robotic Systems standard. Charlie 
Dischinger and David Fitts are Co-Principal Investigators 
on the proposed project. 
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